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Digital  Mapping,  Charting,  and  Geodesy  Analysis  Program  Technical  Review 
of  Vector  Quantization  (VQ)  Decompression  for  the 
National  Imageiy  Transmission  Format  Standard  (NITFS) 


1.0  Introduction 

Requested  by  the  Oceanographer  of  the  Navy,  the  Naval  Research  Laboratory’s  Digital 
Mapping,  Charting,  and  Analysis  Program  (DMAP)  has  performed  a  technical  review  of 
the  Defense  Information  Systems  Agency’s  'Draft  Military  Standard  Vector  Quantization 
(VQ)  Decompression  for  the  National  Imagery  Transmission  Format  Standard  (NITFS)" 
[2],  in  an  attempt  to  insure  that  Naval  requirements  will  be  met.  DMAP  has  observed 
that  the  scope  of  this  document  is  well-defined;  VQ  decompression  and  its  relationship 
to  NITFS  compliant  systems.  In  its  current  form,  this  draft  standard  (referred  to  in  this 
review  as  the  VQ  standard)  requires  few  changes  before  becoming  an  acceptable 
standard  meeting  Naval  requirements.  The  ultimate  association,  however,  between  the 
VQ  standard  and  its  companion  documents  [1],  [3],  and  [4]  should  be  given  more 
consideration.  In  particular,  the  soon-to-be  accepted  Raster  Product  Format  (RPF) 
standard  [4],  which  is  not  referenced  in  the  VQ  standard  despite  its  close  relationship, 
should  be  a  basis  for  defining  the  VQ  file  structure. 

1.1  Compatibility  with  Raster  Product  Format 

The  relationship  between  RPF  files  and  VQ  files  is  not  evident  in  the  VQ  standard. 

RPF  supports  VQ  compressed  images,  as  well  as  raster  images  compressed  by  other 
techniques  or  even  uncompressed  images.  The  VQ  standard  is  much  more  specific  and 
is  apparently  intended  for  use  v^th  individual  images  rather  than  general  products  such 
as  Compressed  ARC  Digitized  Raster  Graphics  (CADRG).  If  this  relationship  is  indeed 
the  case,  it  should  be  explicitly  stated  in  the  VQ  standard. 

Moreover,  VQ  images  could  not  be  easily  read  by  RPF  compliant  software,  even  though 
that  same  image  formatted  in  the  RPF  could  be  read.  This  fact  is  evidenced  by  Figures 
1  to  4,  where  similar  sections  between  the  figures  are  marked  for  easy  association. 

Figure  1  details  an  RPF  frame  file  and  Figure  2  shows  the  VQ  file  structure.  Although 
both  are  similar  to  the  Nl'lF  (Figures  3  and  4),  obvious  differences  exist.  DMAP 
recommends  the  following  additions/changes  to  the  VQ  standard’s  [NITF  image]  (Figure 
7  on  page  13  of  [2])  for  at  least  minimal  agreement  with  the  RPF’s  [frame  file]: 

i.  Add  a  tagged  [color/grayscale  section]  to  the  image  subheader; 

ii.  Add  a  [compression  parameters  section]  to  house  the  [image  display 
parameter  subheader]; 
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Figure  1.  RPF  frame  file  structure  taken  from  f4]. 


[frame  file] 

{1} 

[header  section] 

[location  section] 

_ [coverage  section]  (0,1) 

[compression  section]  (0,1) 

{2} 

[compression  section  subheader] 

{3} 

< compression  algorithm  id>,uint;2 
< number  of  compression  lookup  offset  records >,unit:2 
< number  of  compression  parameter  offset  records >,uint;2 

{2} 

[compression  lookup  subsection]  (0,1) 

{3} 

< compression  lookup  offset  table  offset >,uint;4 
< compression  lookup  table  offset  record  length >,uint:2 
[compression  lookup  offset  table] 

{4} 

[compression  lookup  offset  record]  (1, ...  many) 

{5} 

< compression  lookup  table  id>,uint;2 
< number  of  compression  lookup  records >,uint:4 
<  number  of  values  per  compression  lookup  record  >  ,uint:2 
< compression  lookup  value  bit  length >,uint:2 
< compression  lookup  table  offset >,uint:4 

{3} 

[compression  lookup  table]  (1, ...  many) 

{4} 

[compression  lookup  record]  (1, ...  many) 

{5} 

/compression  lookup  value/,bits:var  (1, ...  many) 

{2}  - 

[compression  parameter  subsection]  (0,1) 

< compression  parameter  offset  table  offset >,uint:4 
< compression  parameter  offset  record  length >,uint:2 

{3} 

[compression  parameter  offset  table] 

{4} 

[compression  parameter  offset  record]  (1, ...  many) 

{5} 

< compression  parameter  id >,uint:2 
< compression  parameter  record  offset >,uint;4 

{3} 

[compression  parameter  record]  (1, ...  many) 

{4} 

_  <  compression  parameter  value  >  ,byte^^r 

{1}  - 

[color/grayscale  section]  (0,1) 

[image  section] 

{2} 

[image  description  subheader] 

{3} 

< number  of  spectral  groups >,uint:2 
< number  of  subframe  tables >,uint;2 
< number  of  spectral  band  tables >,uint:2 
<number  of  spectral  band  lines  per  image  row>,uint:2 
< number  of  subframes  in  east-west  or  left-right  direction >,uint:2 
< number  of  output  columns  per  subframe >,uint:4 
< number  of  output  rows  per  subframe >,uint:4 
<subframe  mask  table  offset >,uint:4 
< transparency  mask  table  offset >,uint:4 
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{2}  Figure  1.  R] 

[mask  subsection]  (04) 

{3} 

[mask  subheader] 

{4} 

< subframe  sequence  record  length >,uint:2 
< transparency  sequence  record  length >,uint:2 

{3} 

[subframe  mask  table]  (0,1) 

{4} 

[subframe  mask  row]  (1, ...  many) 

{5} 

[subframe  sequence  record]  (1, ...  many) 

{6} 

<subframe  sequence  number>,uint:2 

{3} 

[transparency  mask  table]  (0,1) 

{4} 

[transparency  mask  row]  (1, ...  many) 

{5} 

[transparency  sequence  record]  (1, ...  many) 

{6} 

< transparency  sequence  number>,umt:2 

{2} 

[image  display  parameters  subheader] 

{3} 

< number  of  image  rows>,uint:4 
<  number  of  image  codes  per  row>  ,uint:4 
< image  code  bit  length >,uint:l 
< transparent  output  pbtel  code  length >,uint:2 
/transparent  output  pixel  code/,bits.-var  _ 

_  {2} 

[spatial  data  subsection] 

{3} 

[spectral  group]  (1, ...  many) 

{4} 

[subframe  table]  (1, ...  many) 

{5} 

[spectral  band  table]  (1, ...  many) 

{6} 

[image  row]  (1, ...  many) 

{7} 

[spectral  band  line]  (1, ...  many) 

{8} 

-  /image  code/,bitsrvar  (1, ...  many) 

{1} 

[attribute  section]  (0,1) 

[related  images  section]  (0,1) 

[replace/update  section]  (0,1) 


Figure  1.  RPF  frame  file  structure  taken  from  [41  (cont’d). 
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Figure  2.  VO  image  data  structure  taken  from  f2]. 


{1} 

'  [nitf  image  data] 

{2} 

< blocked  image  data  offset >,uint:4  (0, 1) 
[mask  subsection]  (0, 1) 

{3} 

[mask  subheader] 

[block  mask  table]  (0,1) 
[transparency  mask  table]  (0, 1) 


{2} 

[VQ  Header] 

{3}  - 

[image  display  parameter  subheader] 

{4} 

< number  of  image  rows>,uint:4 
< number  of  image  codes  per  row>,uint:4 
< image  code  bit  length >,uint:l  _ 

-  {3} 

[compression  section] 

{4} 

[compression  section  subheader] 

{5} 

< compression  algorithm  id>,uint:2 
< number  of  compression  lookup  offset  records >,uint:2 
< number  of  compression  parameter  offset  records >,uint:2 

{4} 

[compression  lookup  subsection]  (0,1) 

{5} 

< compression  lookup  offset  table  offset >,uint:4 
< compression  lookup  table  offset  record  length >,uint;2 
[compression  lookup  offset  table] 

{6} 

[compression  lookup  offset  record]  (1, ...  many) 

{7} 

< compression  lookup  table  id>,uint:2 
< number  of  compression  lookup  records >,uint;4 
< number  of  values  per  compression  lookup  record >,uint:2 
< compression  lookup  value  bit  length >,uint:2 
< compression  lookup  table  offset >,uint:4 

{5} 

[compression  lookup  table]  (1, ...  many) 

{6} 

[compression  lookup  record]  (1, ...  many) 

{7} 

/compression  lookup  value/,bits:var  (1, ...  many) 


_ {2} 

[compressed  image  data] 

{3} 

[spectral  group]  (1, ...  many)  ■ 

{4} 

[block  table]  (1, ...  many) 

{5} 

[spectral  band  table]  (1, ...  many) 

{6} 

[image  row]  (1, ...  many) 

{7} 

[spectral  band  line]  (1, ...  many) 

{8} 

/image  code/,bits:var  (1, ...  many) 
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[nitf  message]  Figure  3.  NI  FF  message  structure  taken  from  [3]. 

{1} 

[nitf  message  header] 

[nitf  image]  (0, ...  many) 

{2} 

[nitf  image  sub-header] 

[nitf  image  data] 

{1} 

[nitf  symbol]  (0, ...  many) 

[nitf  label]  (0, ...  many) 

[nitf  text]  (0, ...  many) 

[nitf  data  extension  segment]  (0, ...  many) 

[nitf  reserved  segment]  (0, ...  many) 


Figiire  4.  NITF  file  structure  taken  from  [1]. 
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iii.  Increase  the  [compression  section]  to  level  {2}.  Note:  in  the  RPF 
[frame  file],  the  [compression  section]  is  on  the  same  level  as  [image 
section]. 

These  figures  also  show  some  minor  differences  that,  once  changed,  could  make  the 
parallel  sections  correspond  more  closely.  For  instance,  in  Figure  1,  the  name  [subframe 
table]  is  used  at  a  structural  level  where  the  name  [block  table]  appears  in  figure  2.  Do 
these  names  and  locations  imply  that  a  subframe  in  RPF  corresponds  to  a  block  in  a  VQ 
image?  If  so,  then  the  correspondence  should  be  clarified  in  the  RPF  or  VQ  standard. 

1.2  VQ  Factors 

Section  6.4  of  the  VQ  standard  states  that  "appropriate  VQ  factors"  lead  to  high-quality 
images.  What  are  these  factors?  Since  these  factors  are  apparently  used  to  produce  the 
image,  will  the  user  of  VQ  compressed  data  have  access  to  all  factors?  The  quantity  and 
use  of  metadata  (i.e.,  information  about  data)  needs  to  be  clarified  in  the  VQ  standard. 

If  no  future  plans  have  been  developed  for  including  such  information  with  VQ 
compressed  images,  some  measure  of  data  quality  should  be  investigated  as  part  of  the 
VQ  standard.  The  Vector  Product  Format  (VPF),  as  an  example,  records  metadata  at 
varying  levels  of  detail. 


2.0  List  of  Essential  and  Suggested  Modifications 

The  following  list  supplies  comments  classified  as  "essential"  or  "suggested."  Page/section 
numbers  and  line/figure/table  positions  are  given,  as  well  as  recommended  alternate 
text. 

KEY  P  =  page  L  =  line  S  =  section 
T  =  table  F  =  figure 

2.1  Essential 

1.  PI  S  1.1  LI  Are  there  plans  for  developing  a  suite  of  standards  for 

different  types  of  compression/decompression,  or  will  this  be  a 
unique  standard?  For  example,  the  field  IC  in  [1]  currently  has 
as  possibilities  NC  or  C0-C3.  Will  a  standard  be  developed  for 
each  of  the  C0-C3?  If  so,  this  fact  should  be  introduced  in  the 
VQ  standard.  As  an  aside  note,  the  M4  and  C4  options  are 
not  listed  in  [1]. 

2.  P  1  S  1.2  L  1  The  scope  of  the  VQ  standard  is  contradicted  by  this  sentence. 

Are  compression  details  provided? 
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3.  P  5  S  4.3  L  9  Insert  "(see  figure  2)"  after  the  sentence  ending  "  ...  field  of  the 

NITF  file." 

4.  P  5  S  4.3  L  10  An  incorrect  reference  to  a  figure  is  made  in  this  sentence: 

Decompression  of  the  VQ  data  is  shown  in  figure  2.  This  figure 
number  should  be  3. 

5.  P  5  S  4.3  L  12  Omit  the  phrase  "compression  is  achieved"  from  this  sentence. 

Compression  is  achieved  whether  or  not  the  codebook  contains 
all  possible  pixel  kernels. 

6.  P  5  FI  From  this  figure  of  compression  process  flow  the  color  table 

generation  and  the  codebook  generation  appear  to  be 
independent  processes,  both  emanating  from  the  input  image 
data.  Other  figures  (3,  4,  and  5)  and  sections  of  text  (Section 
5.2. l.b,  last  sentence)  indicate  that,  during  decompression, 
color  decompression  occurs  after  spatial  decompression. 

Figure  1  should  indicate  the  reverse  order,  if  it  is  necessary  for 
compression  as  well. 

7.  P  7  S  4.5  L  6  The  definition  of  idepth  is  not  phrased  correctly.  Idepth  is  the 

size  in  bytes  of  one  color  value  for  the  input  image  (rather 
than  the  size  of  the  color  palette  as  currently  stated). 

8.  P  7  S  4.5  L  20  Refer  to  the  compression  codebook  as  simply  codebook.  There 

are  multiple  occurrences  of  compression  codebook  throughout 
the  VQ  standard.  NRL’s  MDFF  Laboratory  uses  the  name 
decompression  codebook. 

9.  P  10  S  5.2.3.2  L  2  A  precise  reference  to  [1],  page  and/or  section,  needs  to  be 

given  regarding  masking  as  it  relates  to  VQ  images. 

10.  P  11  S  5.2.3.3b  L  1  The  name  <  number  of  compression  lookup  tables  >  does  not 

exist  in  figure  7. 

11.  P  11  S  5.2.3.3c  L  1  The  name  <  number  of  compression  lookup  tables  >  does  not 

exist  in  figure  7. 

12.  P  12  S  5.2.3.4e  L  2  Instead  of  "image  subheader"  the  description  [image  display 

parameter  subheader]  should  be  used. 

13.  P  13,  14  [Compression  lookup  offset  record]  and  [compression  lookup 

table  offset  record]  are  used  interchangeably  in  figure  7  and  the 
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definitions  of  the  image  data  section.  A  standard  name  should 
be  used. 

14.  P  15  S  5.4(16)  L  3  [Lookup  record]  should  be  clarified  with  its  appropriate  name: 

{compression  lookup  record]. 

15.  P  16  S  6.3  L  2-3  More  specifics  should  be  given  regarding  "orders  of 

magnitude."  What  other  decompression  methods  were  used  in 
the  study? 

2.2  Suggested 

16.  PI  S  1.1  L  5-6  Reword  this  sentence  as  follows:  "The  steps  involved  in 

decompressing  images  compressed  with  VQ  are  fully  described 
by  this  standard." 

17.  P  4  S  3.2v  Block  is  used  to  represent  different  entities  in  this  review. 

Here  it’s  used  to  represent  the  kernel  of  size  v  x  h,  whereas  in 
other  parts  of  the  text  (e.g.,  page  11,  line  46  and  page  6,  figure 
2),  it’s  used  to  signify  sections  of  an  image.  Two  separate 
terms  would  be  helpful;  e.g.,  kernel  and  block. 

18.  P  5  S  4.2  L  1  This  sentence  should  be  more  specific.  For  example,  what 

types  of  image  data  are  appropriately  compressed  using  a  lossy 
technique?  More  importantly,  what  image  data  are  not  to  be 
compressed  in  this  fashion?  A  reference  to  the  NITFS 
handbook,  which  is  referenced  in  [2],  should  be  given. 

19.  P  5  S  4.2  L  6-7  "The  codebook  and  the  color  LUT  are  included  in  the  file  as 

overhead  information."  NRL’s  MDFF  Laboratory,  in  its 
construction  of  Compressed  Aeronautical  Chart  (CAC),  stores 
multiple  images  on  CDROM,  with  each  image  stored  \vith  its 
own  codebook  and  only  one  palette  stored  for  each  zone  of 
images  (maximum  of  5  palettes  per  CDROM).  Has  this  type 
of  efficiency  been  investigated  for  "similar"  VQ  images?  If  so, 
are  there  future  plans  to  incorporate  such  changes? 

20.  P  6  F  2  For  completeness,  this  figure  should  include  (but  not 

emphasize)  the  information  in  figure  4  of  this  review,  which 
shows  other  NITF  sections  such  as  the  symbol  section  and  label 
section. 
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21.  P  6  S  4.4  L  2  The  text  should  read  " ...  input  the  compressed  image  data, 

which  includes  the  image  codes,  codebook(s),  and  color  table 
..."  to  agree  with  figure  3. 

22.  P  7  L  3  Insert  "(v  x  h)”  after  the  word  "pixels"  to  indicate  the  number  of 

kernel  pixels. 

23.  P  7  L  14  Insert  "24-bit  (3-byte)"  after  the  word  "digitized"  for  a  better 

description. 

24.  P  7  L  15  The  codebook  dimensions  need  clarification.  This  sentence 

could,  for  example,  be  reworded  as  follows:  " ...  codebook 
length  of  4096  bytes  with  a  12  bit  (1.5  byte)  code_size,  with  3K 
bytes  for  miscellaneous  overhead,  which  includes  an  8-bit  (1- 
byte)  color  table  that  is  IK  in  size." 

25.  P  9  S  5.2.1b  L  4  Insert  "from  left  to  right"  after  the  word  continue. 

26.  P  10  S  5.2.3.1  For  completeness,  include  this  description  of  COMRAT: 

idepth  (bytes)  x  8  (bits/byte)  =  24  bits,  divided  by  the 
theoretical  compression  ratio  (32),  yielding  a  bpp  of  0.75.  To 
be  complete,  Section  3.2  should  define  bpp  as  well. 

27.  P  11  S  5.2.3.3a  This  section  should  be  supplemented  with  an  example. 

28.  P  11  In  the  equation  computing  v,  the  quotient  <  number  of  image 

rows>,  at  this  point  in  the  standard,  does  not  portray  the 
quantity  the  reader  expects;  i.e.,  roughly  speaking,  "number  of 
image  codes  in  the  vertical  direction."  The  <  number  of  image 
rows>  should  more  clearly  refer  to  compressed  data. 

29.  P  11  S  5.2.3.4  L  2  A  definition  of  IMODE  would  be  helpful,  or  the  reader 

should  be  referred  to  [1]. 

30.  P  11  S  5.2.3.4  L  9  Rather  than  "NITF  VQ  image  section"  the  phrase  "[compressed 

image  data]  group"  should  be  used. 

31.  P  12  S  5.2.3.4d  L  2  The  first  64  in  "64  x  64"  should  be  noted  as  the  determination 

of  the  64  [image  rowjs. 

32.  P  12  S  5.2.3.4e  L  2  The  second  64  in  "64  x  64"  should  be  noted  as  the 

determination  of  the  64  [spectral  band  linejs. 
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33.  P  13  F  7 


Since  <  number  of  compression  parameter  offset  records  >  is 
defined  to  be  zero  for  VQ  images  (Section  5.4  (13)  page  14), 
an  indication  in  this  figure  such  as  "::  =  0"  following  "unit:  =2" 
would  reiterate  this  fact. 

34.  P  16  S  6.1  LI  More  specifics  should  be  given  regarding  the  selection  criteria 

and  the  results. 


3.0  Editorial  Comments 

All  editorial  comments  are  included  in  the  following  list. 

35.  P  ii  S  5.2.3.1-3  These  sections  have  an  indentation  error.  Also  the  page 

number  "ii"  is  missing  from  the  bottom  of  this  page. 

36.  P  hi  L  12  This  Table  does  not  appear  on  page  4,  but  on  page  19.  The 

table  name  should  be  "Data  Types  and  Their  Abbreviations." 

37.  P  1  S  1.5  L  2  Omit  "Vector  Quantization"  since  Section  1.1  has  already 

defined  VQ. 

38.  P  2  S  2.1.1  L  11  The  "S"  in  NITFS  represents  Standards,  whereas  on  the 

following  page  in  Section  3.1m,  the  "S"  represents  Standard. 
Reference  [1]  uses  Standards. 

39.  P  4  The  page  number  is  missing. 

40.  P  5  S  4.3  L  11  Replace  "compressed  image  codes"  with  just  "image  codes." 

41.  P  7  L  7  The  symbol ")"  is  missing  after  the  sentence  ending  "  ...  would 

be  one." 

42.  P  10  S  5.2.2a  L  1  Replace  the  word  above  with  the  phrase  "in  section  5.2.1." 

43.  P  10  S  5.2.2a  L  3  Reference  figure  2  after  the  phrase  "NITF  image  subheader." 

44.  P  10  S  5.2.2a  L  6  The  comma  should  be  placed  inside  quotation  marks. 

45.  PH  S  5.2.3.3b  L  2  /Compression  lookup  va/wei/ should  be  /compression  lookup 

value/s. 

46.  P  12  S  5.2.3.4d  L  2  /Image  codes/  should  be  /image  code/s. 
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47.  P  12  S  5.2.3.4e  L  2  /Image  codes/  should  be  /image  code/s. 

48.  P  12  S  5.3  LI  Insert  a  hyphen  between  STD  and  2500: 

49.  P  12  S  5.3a  L  4  Insert  a  hyphen  between  STD  and  2500: 


MIL-STD-2500. 

MIL-STD-2500. 


50.  P  19  T  1  Alphabetic  is  misspelled:  Alaphabetic.  Also,  the  abbreviations 

could  be  developed  in  a  more  consistent  manner.  For 
example,  sint  (signed  integer),  uint  (unsigned  integer),  snum 
(signed  number),  and  unum  (unsigned  number). 


4.0  Recommendations 

With  the  few  exceptions  noted  in  this  review,  the  VQ  draft  standard  is  a  well-developed, 
comprehensive  design.  Its  written  exposition  on  VQ  decompression  is  an  improvement 
over  that  given  in  the  CADRG  specification.  The  lack  of  dependence  on  any  one  VQ 
compression  technique  further  adds  to  its  robustness.  Qne  drawback,  as  can  be  the  case 
with  such  a  standard,  is  its  apparent  lack  of  relationship  to  other  standards  in  its  class. 
For  example,  the  RPF  allows  for  storage  of  imagery  compressed  via  a  VQ  technique,  and 
yet  RPF  is  not  referenced  in  the  document.  DMAP’s  main  recommendation:  Describe 
the  circumstances  under  which  each  will  be  used. 

The  "essential"  comments  noted  in  Section  2.0  should  be  incorporated  into  the  written 
document.  These  changes  will  improve  the  standard,  from  both  a  reader  and 
programmer  point-of-view.  In  addition,  the  "suggested"  comments  need  to  be  addressed 
before  further  advancement  of  the  VQ  standard.  Finally,  the  editorial  changes  listed  in 
Section  3.0  should  be  made. 
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Appendix.  Acronyms. 
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bpp 

CAC 

CADRG 

DMAP 

MDFF 

NITF 

NITFS 

NRL 

RPF 

VPF 

VQ 


bits  per  pixel 

Compressed  Aeronautical  Chart 

Compressed  ARC  Digitized  Raster  Graphics 

Digital  Mapping,  Charting,  and  Geodesy  Analysis  Program 

Map  Data  Formatting  Facility 

National  Imagery  Transmission  Format 

National  Imagery  Transmission  Format  Standard 

Naval  Research  Laboratory 

Raster  Product  Format 

Vector  Product  Format 

Vector  Quantization 
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